DAC is based on the notion that individual users are owners of objects and , therefore have discretion over who should be authorized to access the object and in which mode (e.g., read or write). Ownership is usually acquired as a consequence of creating the object or via specified ownership assignment. DAC allows the owner to determine who will have access to objects they control. An example of DAC includes user controlled file permissions.
DNS zone transfers must utilize these access controls to restrict access to those servers that can ""pull"" a zone. If an adversary is able to obtain a zone file, all resources within the zone are then known to the adversary as host names and addresses will be identified.
A slave updates its zone information by requesting a zone transfer from its master server. In this transaction, the risk for the slave is that the response to its request is not in fact from its authorized master but rather from an adversary posing as the master. In this scenario, such an adversary would be able to modify and insert records into the slave's zone at will. To protect against this occurrence, the slave must be able to authenticate the master to provide assurance that any zone updates are valid.
The risk to the master server in this situation is that it would honor a request from a host that is not an authorized slave, but rather an adversary seeking information about the zone. To protect against this possibility, the master must first have knowledge of what machines are authorized slaves. Then the master must authenticate each slave when that server requests a zone transfer.
DNS must enforce these access control policies over the DNS zone transfers to ensure data protection and integrity of the zone files. Access controls are employed at the zone transfer level to restrict and control access to DNS zone data, thereby providing increased information security for the organization. |